本篇是最後五天方法回顧的第一篇。

本篇要回答：五個故事各踩在不同的技術層，為什麼說它們是同一種事故？

五種局部成功

把五個故事各自最理直氣壯的一句話排在一起：

1. 技術問題都問完了。（故事一，需求層）
2. 我的 Python 能執行。（故事二，環境層）
3. Python 語法合法。（故事三，語言層）
4. lint 規則全部通過。（故事四，工具層）
5. Publisher 已把訊息送出。（故事五，分散式層）

每一句都是真的。每一句都有證據。每一句，都與「使用者真正需要的結果已經發生」無關。

共同結構

五案共用同一條劇本：

局部元件或角色完成自己的工作
        ↓
留下局部成功的證據
        ↓
局部結果被擴張解讀為整體成功
        ↓
端到端結果沒有發生
        ↓
所有人都表示「我這邊正常」

危險的一步永遠是第三步——擴張解讀。規格問完了被讀成「需求清楚了」；IDE 能跑被讀成「程式沒問題」；語法合法被讀成「資料正確」；lint 全綠被讀成「語意不變」；發布成功被讀成「設備完成」。證據本身從不說謊，說謊的是我們替證據加上的引伸義。

It Works on My Machine 的完整版

這句話通常被當成開發者的招牌藉口，但拆開看，每一個抽象層都有自己的版本：需求層的 my machine 是「我的問題清單」，環境層是「我的 interpreter」，語言層是「我的直譯器沒報錯」，工具層是「我的規則集」，分散式層是「我的那一段鏈路」。每一層都有一台自己的 machine，每一台上面都 works——組合起來的系統卻不 work。

所以事故調查要找的從來不是「誰在說謊」——多數時候沒有人說謊——而是主張與證據之間的缺口：你說完成，你的證據支撐到哪一層？

本篇結論

每一層都有自己的不在場證明，只有整套系統還留在現場。

下一篇（Day 27）處理讓調查成為可能的前提：證據保存——沒有保存證據，就只能靠每個人回憶自己的清白。